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BACKGROUND OF THE INVENTION 



The present invention relates to a method for providing 
software technical support from a remote location via, for 
example, the Internet. More specifically, the present inven- 

35 tion provides a method by which software upgrades and 
fixes for software bugs may be incorporated into a custom- 
er's software from the remote location. 

Once a software producing company has sold a software 
product to its customer, it is extremely important to keep 

40 track of these customers and to update the software peri- 
odically. No software program is ever bug free; in fact, the 
software industry is quite accustomed to re-releasing newer 
versions of software programs on a periodic basis in order to 
correct errors in the software. These later releases may add 

45 new features to the software, may correct minor problems, 
or often correct critical errors in the software. Because the 
performance of a software program is important for 
customers, it is in a software company's best interest to 
release these later versions of software to its customers and 

50 to insure that the newer software versions are received and 
installed correctly. 

However, numerous obstacles are present that thwart even 
the best efforts of a conscientious software company to 
periodically update its software products with newer ver- 

55 sions for all of its customers. One problem is that few 
customers who buy a software program go through the 
formalities of registering the program and sending the 
registration back to the software company. A registration 
form allows a software company to keep track of purchasers 

60 of its software, their addresses, contact persons, the version 
purchased, etc. However, few such software registration 
forms are received by software vendors. This makes it 
extremely difficult for a software company to determine to 
whom regular updates should be sent. For those software 

65 companies that update software regularly (such as quarterly) 
or may need to correct critical software bugs, this lack of 
software registration presents a real problem. And even if a 
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registration form has been received, it is often difficult to technical support to its customers from a remote location via 

figure out exactly to whom the new software version should the Internet. When the end user begins operating the ven- 

be directed. Individuals change roles within an organization, dor's software, dialog boxes give the user the opportunity to 

organizations merge, engineers leave, etc., all making it register the software with the vendor. If the user decides to 

extremely difficult to figure out to whom within an organi- 5 register the software, a connection between the user's plat- 

zation a new software version should be sent. It is also form ^ vendor * established via the Internet to effect 

important that new versions of software be sent to a respon- registration. Moreover, each time thereafter that the user 

sible person within the organization to ensure that all com- be S ms operating the software, an Internet connection to the 

puters running the software are updated with the new vendor is established for me purpose of determining whether 

version, and that the installation is done correctly. However, 10 a software upgrade is necessary. Version data for each of the 

even with such competent individuals, errors in installation. software's modules as well as any critical bug data known 

* , . , , . t , . . f g. by the vendor are downloaded to the user's platform for 

Another problem with releasing new versions of software 3 . . , t ' 

r . , , $ » » ». • y j comparison to the user s current version of the software, 

to customers is the problem of distribution. In order to „„ , , . , . 

. • r .u r* *u j * Where the downloaded version data agree with the user s 

release a new version of the software, the vendor must , . . , , . & . , it _ 

. a * j* i * i_ i j jl c*. k module versions, and where there are no known bugs, the 

purchase floppy or compact disks to hold the software, copy *5 > &> 

f, rr , S , * • i j • i . . . T user s software remains unchanged. However, if the com- 

the software onto the disks, label the disks, determine who ... f . , c . 

. j*. jilij panson reveals that one or more of the user s software 

the appropriate customers and contacts are, and label and F " , .. . . ■ c T j X i iT 1- , 

mail fhese disks to the correct individual. But as mentioned ™ dules m outda,ed or * fected m f a cn " cal *^ 

above, even if these disks containing the latest software boxes are P' es * n,ed to the J user j or . "f* . modl ? le 

version arrive at the correct location, there is no guarantee 20 requesUng whether an upgrade « desired. A list > main- 

that the software wiU be installed correctly. Any problems £f d °f th f e , modu ] e ! f ° r wh, ' h '""Pf ad ? fj e< l uested - 

encountered with the software, either due to bugVor incor- ^ aU , of m0d f* b ™ A b ? n Cb " m T™"' 

reel installation will undoubtedly be blamed upon the soft- * e la,es ' v 'f 00 ° f ,he f dule ! 10 . he 'W 1 * ^ are 

.„ t . t u „ « , .1. ' „a„,«« Jl downloaded from the vendor and written over the corre- 

ware company that has sold the software program. ,. . , , , . . , . . 

. r * sponding outdated modules on the user s platform. 

It is clearly in the best interests of a software company to ^ A - ... , - , . 

• j * j c c * ■ 1 According to another embodiment of the invention, a 

ensure that updated versions of its software are timely , . ° . , ... , „ , 

. , . *r . « . . - . .... c ./ method is provided by which a vendor may effectively 

received by the correct individuals within one of its , f . 4 . - e ; c J 

J , . . * 1 1 j troubleshoot errors m the operation of its software from a 

customers, and correctly installed. t t t . . . t r t 

' . . remote location via the Internet. When a user encounters an 

Another problem encountered by software companies is 3o error m the operation of the vendor's software, operation of 

the identification and correction of software bugs encoun- ^ fa suspended and „ Internet connection to the 

tered by customers in the course of using their software. vendor fe establishe d by which the error is reported and 

Typically, a customer receiving an error message while known critical bug data are downloaded to the user's plat- 
using software will call the software company and relate the form. The critical bug data are compared to the state of the 
circumstances surrounding the problem. Such a user may be 35 user's software to determine whether the error corresponds 
able to relate generally what he was doing at the time, t0 any known bugs previously documented by the vendor, 
describe the problem that occurred, and report any error ID Where the error corresponds to a known bug, the user is 
number that was produced. However, it is rare that specific grven me option, e.g., via a dialog box, to download a 
details involving computer configuration, other programs software fix from the vendor. This may be, for example, a 
running, and the status of internal variables are reported. ^ replacement module to overwrite the module with the bug. 
Essentially, the problem is that the customer is in a location Where, however, the error does not correspond to any 
isolated from the software company when the problem known bug, software on the vendor's platform determines 
occurs and has no means of transferring a "snapshot" of his wna t information must be uploaded from the user's 
system at the time the error occurs. platform, subject to the user's authorization, in order to 

Of course, if the customer discontinues use of the 45 recreate on the vendor's platform the conditions under 
software, ignores the problem, or otherwise chooses not to which the error occurred; this for the purpose of trouble- 
contact the software company with news of the error, the shooting the error locally, i.e., on the vendor's platform. If 
software company is put at a disadvantage. In these the user does not authorize the upload, the vendor supplies 
situations, because the vendor does not hear about the information to the user regarding the nature of the error (to 
occurrence of the problem, it is not given the opportunity to 50 the extent possible) and an appropriate contact person with 
correct it. Because errors in software can be extremely whom the user may attempt to solve the problem, 
complex and subtle, it is very important for a software Thus, the present invention provides a method for upgrad- 
company to know exactly the circumstances under which the i ng first software. According to the invention, in response to 
problem occurred in order to be able to reproduce the operation of the first software on a first platform, a connec- 
problem and to solve it. For customers using the software at 55 uorj is established between the first platform and a remote 
a remote location on a remote computer, it is unlikely and platform. Where first version data associated with the first 
extremely difficult that a customer will be able to transfer all software are different from second version data from the 
of the information concerning such a problem back to the remote platform, a portion of the first software is overwritten 
software company. with first updated code from the remote platform. 

It is therefore desirable that a technique be provided by 60 The present invention also provides a method for trouble- 

which a software vendor can track customers, upgrade shooting first software. According to the invention, in 

customer software with newer versions, and correct software response to an error in operation of the first software on a 

bugs from remote locations. first platform, a connection is established between the first 

„ T t» ™,r. .*T,r™™«*, platform and a remote platform. Where the error corre- 

SUMMARY OF THE INVENTION 6J ^ lQ knQwn error ^ bom tne rerao[e platfonn> a 

According to the present invention, techniques are pro* portion of the first software is overwritten with updated 

vided by which a software vendor may provide software code. 
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A further understanding of the nature and advantages of 
the present invention may be realized by reference to the 
remaining portions of the specification and the drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 5 

FIG. 1 is a diagram of a network environment in which 
specific embodiments of the present invention may be 
implemented; 

FIG. 2 is a flowchart illustrating remote registration of 
software according to a specific embodiment of the inven- 
tion; 

FIG. 3 is a flowchart illustrating remote upgrading of 
software according to a specific embodiment of the inven- 
tion; 15 

FIGS. 4a and 4b are flowcharts illustrating remote 
troubleshooting of software according to specific embodi- 
ments of the invention; 

FIG. 5 is a flowchart illustrating access of help files 
according to a specific embodiment of the invention; 20 

FIG. 6 illustrates an example of a computer system that 
may be used to execute the software of an embodiment of 
the invention; and 

FIG. 7 shows a system block diagram the computer 
system of FIG. 6. 

DESCRIPTION OF SPECIFIC EMBODIMENTS 

FIG. 1 is a simplified representation of a network envi- 
ronment in which specific embodiments of the present 30 
invention may be implemented. Customer platform 100 is a 
workstation or personal computer (PC) on which software 
from a particular vendor is installed. An example of the type 
of software installed on customer platform 100 which may 
be employed with the present invention is described in 35 
commonly assigned, copending U.S. patent application Ser. 
No. 08/958,778 for METHOD AND APPARATUS FOR 
AUTOMATED CIRCUIT DESIGN, filed simultaneously 
herewith, the entire specification of which is incorporated 
herein by reference. Software used to design circuits such as, ^ 
for example, programmable logic devices, is extremely 
complex and, as such, is the type of software which could 
especially benefit from the features of the present invention. 
That is, such software typically requires its vendor to 
maintain a large technical support capability to ensure 45 
customer satisfaction. It will be understood, however, that 
the techniques described herein may be applied to a wide 
variety of software without departing from the scope of the 
invention. 

Customer platform 100 resides on a local area network 50 
(LAN) 102 with a file server 104 which is, in turn, connected 
to the Internet 106 via a router 108. Vendor platform 110 is 
a file server which is remote from LAN 102 and is connected 
to Internet 106 via router 112. It will be understood that the 
network environment illustrated in FIG. 1 is one example of 55 
an environment in which the present invention may be 
practiced, and that a wide variety of network configurations 
may be employed without departing from the scope of the 
invention. 

According to the invention, a customer may effect regis- 60 
tration of software with the vendor via the Internet. A 
specific embodiment of this aspect of the invention will now 
be described with reference to flowchart 200 of FIG. 2. 
When the customer or end user begins operating the soft- 
ware on her platform (step 202), the software determines 65 
whether access to the Internet is available (step 204). If not, 
a dialog box is presented instructing the user to contact the 
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software vendor for registering her copy of the software 
(step 206). If, on the other hand, Internet access is available, 
the software presents a dialog box prompting the user to 
authorize registration of the software (step 208). If the user 
does not authorize moving forward with the registration 
process (step 210), the software registration routine ends and 
the user may proceed with normal operation of the software. 
However, if the user does give authorization, an Internet 
connection is established between the user's platform and 
the vendor (step 212) by which registration of the software 
is effected (step 214). Once the software is registered, 
normal operation of the software on the user's platform may 
proceed. 

Several advantages result from software registration 
achieved in the above-described manner. Because of the 
automated nature of the registration process described 
herein, the registration of a software product employing this 
process is much more likely to occur than if the onus for 
effecting registration is placed entirely on the customer as in 
the case, for example, of registration by mail. And, when 
vendors know who has purchased their software, they are in 
a better position to provide the technical support necessary 
to enable their customers to use their products to their 
greatest advantage. In addition, with accurate customer data, 
vendors are better able to develop product design strategies 
which are responsive to the needs of their customer base. 

FIG. 3 is a flowchart 300 illustrating a method by which 
a customer's software may be upgraded according to a 
specific embodiment of the invention. When the customer or 
end user begins operating the software on her platform (step 
302), the software determines whether access to the Internet 
is available (step 304). If not, and the user's software is older 
than some predetermined aging period, a dialog box is 
presented instructing the user to contact the software vendor 
for determining whether she has the latest version of the 
software (step 306). If, for example, the software is updated 
quarterly, the dialog box is presented if the version of the 
software on the user's platform is more than three months 
old. 

If, on the other hand, Internet access is available, the 
software presents a dialog box prompting the user to autho- 
rize connecting to the vendor for this determination (step 
308). In either case, the user is also given the option of 
indicating that she does not wish to be asked again regarding 
updating the software. If the user does not authorize the 
connection (step 310), the software upgrade routine ends 
and the user may proceed with normal operation of the 
software. However, if the user does give authorization, an 
Internet connection is established between the user's plat- 
form and the vendor (step 312) by which the upgrade 
process may proceed. 

Data are downloaded from the vendor to the user's 
platform regarding the most current version of the software 
and any critical software bugs known to the vendor (step 
314). These data are used to determine whether the user's 
software is appropriately updated and whether any of the 
modules of the software are affected by the known bugs. 
Each individual module of the user's software is selected 
and compared to the version and critical bug data (step 316). 
Where the version number of the selected module and the 
version data agree (step 318) and where modules remain 
which have not been checked (step 319), another module is 
selected for comparison. If at step 318 the selected module 
is determined not to be the latest version, it is then deter- 
mined whether the critical bug data identify the selected 
module (step 320). If not, a dialog box is generated asking 
the user whether the module should be upgraded (step 322). 
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If the user indicates that the module should be upgraded, it 
is added to an upgrade list (step 324). If at step 320 the 
selected module is identified as having a critical bug, a 
dialog box describing the nature of the bug is generated 
asking the user whether the module should be upgraded 
(step 326). Again, if the user authorizes the upgrade, the 
module is added to the upgrade list. 

According to a specific embodiment of the invention, the 
critical bug data downloaded from the vendor's platform 
may be employed to determine whether a particular user is 
likely to encounter a known bug. For example, where the 
software is for designing programmable logic devices, it 
could be the case that a particular bug only affects operation 
of the software with respect to a particular family of PLDS. 
By studying previous use data associated with the software, 
it may be determined whether the user has ever worked with 
that device family and, therefore, whether the bug should be 
fixed. In one embodiment, the software is simply not ana- 
lyzed with respect to such a bug. In another embodiment, the 
user is given the option of deciding whether the bug should 
be fixed. 

Once all of the modules have been checked (step 328) it 
is determined whether any modules have been placed on the 
upgrade list (step 330). Where no modules have been 
designated for upgrade, the upgrade software routine ends 
and the user may proceed with normal operation of the 
software. If, however, an upgrade has been requested by the 
user for at least one module, the user's software is shut down 
(step 332) and new modules are downloaded from the 
vendor to the user's platform (step 334) and written over the 
corresponding modules on the upgrade list (step 336). A 
diagnostic of the newly configured software modules is then 
performed to ensure proper operation (step 338). Once the 
diagnostic indicates proper operation, the routine ends and 
normal operation of the software may proceed. 

Due to the nature of the above-described procedure, the 
difficult task of ensuring that customers are using the most 
recent version of a vendor's software is greatly facilitated. 
As will be understood, the upgrading of software, especially 
complex design tools, is desirable for a number of reasons. 
For example, it is virtually impossible to discover all of the 
bugs in a software program before distributing it to custom- 
ers. In fact, it is the use by a large customer base which 
produces all of the conditions needed to expose any hidden 
problems. Therefore, once such problems are exposed, por- 
tions of the software affected by the bugs must be upgraded. 
In addition, as improvements to a software package are 
developed, it is in a vendor's interest to make sure that its 
customers can take advantage of the improvements. 

However, as discussed above, registration of software by 
a customer base has historically been inconsistent. This has 
provided an obstacle to upgrading software packages in that 
the vendor's information about its customer base has been 
correlatively inconsistent. Even where registration is 
accomplished, it is often difficult for a vendor to identify the 
appropriate individual in a customer's organization to effect 
the upgrade due to the fact that people frequently change 
their employment situations. 

The manner in which software upgrades have been tra- 
ditionally effected has also been problematic. In addition to 
the difficulties associated with identifying customers and 
contacts, the distribution of the new code on some digital 
storage medium is both costly and time consuming. 
Moreover, once the new code is in the hands of the customer, 
there is no guarantee that it will be installed correctly on the 
customer's system. In fact, many of the problems that 
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customers encounter in the use of software is a direct result 
of incorrect installation and/or configuring of the software. 
These problems are exacerbated by the fact that, especially 
during the period immediately following release of new 

5 software, several upgrades a year may be necessary. 

The software upgrade method described herein addresses 
each of these problems. Because the user is asked each time 
she boots up when an upgrade is available and/or 
recommended, it is much more likely that each user will 

10 have the latest version of the software, no matter how many 
upgrades occur. Moreover, the necessity for keeping track of 
the appropriate contact person at each customer is elimi- 
nated in that, because the upgrade is done directly with each 
user, there is no longer a role for such an individual in the 

!5 transaction. The cost and delay which characterized previ- 
ous distribution schemes is also no longer an issue. 
Shipping, production, and advertising costs are virtually 
eliminated, and the only delay is due to the customer's 
refusal to authorize an upgrade. Finally, because installation 

20 and configuration of the software is exclusively under the 
control of the vendor, the incidence of incorrect installations 
should be dramatically reduced. In addition, if a vendor has 
accurate records regarding its customer base (as would be 
the case, for example, where a vendor employs the regis- 

25 tration process described above with reference to FIG. 2), it 
could independently track whether or not specific customers 
are using the most current version of their product by 
keeping track of the customers who have requested an 
upgrade. Simply by being aware of the current version being 

30 used by its various customers, a vendor will be able to 
provide a greater level of customer service. 

FIG. 4a is a flowchart 400 illustrating a technique by 
which a diagnostic routine may be performed on software on 
a user's platform from a remote platform. When, during 

35 operation of software on a user's platform (step 402), either 
an error occurs, the user indicates that in her opinion an error 
has occurred, or the user wishes to requests an enhancement 
to the software (step 404), the software determines whether 
access to the Internet is available (step 406) for the purpose 

40 of connecting to the vendor of the software. If Internet 
access is not available, a dialog box instructs the user to 
contact the vendor, providing, for example, the name, phone 
number, and e-mail address of an appropriate contact person 
(step 407). If, however, Internet access is available, a dialog 

45 box is generated which queries the user as to whether remote 
troubleshooting should begin (step 408). If the user responds 
affirmatively (step 410), a connection between the user's 
platform and the software vendor is established via the 
Internet (step 412) and, if an error is indicated (step 413), a 

50 critical bug table is downloaded from the vendor's platform 
to the user's (step 414). Otherwise, the routine proceeds 
directly to step 437. The critical bug table contains a list of 
known bugs, each of which has an associated condition list 
which is a list of internal conditions of the software by which 

55 the associated critical bug is characterized. These internal 
conditions represent the state of internal variables in the 
software after the critical bug has occurred. 

A critical bug is selected from the table (step 416) and a 
condition is selected from the condition list associated with 

60 the selected critical bug (step 418). If the selected condition 
matches an internal condition of the user's software (step 
420) and there are conditions in the list which have not been 
checked (step 422), the next condition in the condition list 
is selected. If, the routine makes it through all of the 

65 conditions in the list, i.e., all of the conditions in the list 
match the internal conditions of the user's software, the 
associated critical bug is assumed to be the cause of the 



US 6,21 

9 

software error and is reported as such to the user via a dialog 
box (step 424). However, as soon as the routine encounters 
a single condition in the condition list which does not match 
the internal state of the software, and where all of the critical 
bugs in the critical bug table have not been checked (step 
426), the next bug in the table is selected for comparison of 
its condition list to the software. 

Once a known bug is reported to the user at step 424, the 
user is asked whether the software should be upgraded to 
correct the bug (step 428). In response to the user's 
authorization, the user's software is shut down (step 430) 
and software modules corresponding to the identified bug 
are downloaded from the vendor's platform and written over 
the corresponding modules on the user's platform (step 
432). A diagnostic is then run to ensure that the software is 
correctly configured and operational (step 434). If at step 
428 the user does not authorize the upgrade, she is instructed 
to contact the vendor as described above (step 407). 

Where at step 426 all critical bugs have been checked and 
no matches found, a dialog box is generated by which the 
user is informed that the error is likely due to an unknown 
bug (step 436). Authorization is then requested to upload any 
necessary files from the user's platform for troubleshooting 
of the problem on the vendor's platform (step 437). If the 
user grants authorization to upload the requested files (step 
438), a list of files and other necessary information regarding 
the user's system and the state of the software is compiled 
and presented to the user to obtain a second, informed 
authorization for the upload (step 440). Where the user has 
reviewed the list and given authorization, the information is 
uploaded to the vendor's platform (step 444), confirmation 
of which is transmitted back to the user (step 446). With the 
user's files and the other information from the user's 
systems, the vendor may then recreate the conditions under 
which the failure occurred, thereby reproducing and, 
hopefully, correcting the problem. If authorization for the 
upload of information is not granted in either of steps 438 or 
442, the user is instructed to contact the vendor as described 
above (step 407). 

FIG. 4b is a flowchart 401 illustrating another technique 
by which a diagnostic routine may be performed remotely 
on software on a user's platform. Steps 402 through 436 are 
the same as described above with reference to FIG. 4a. 
However, if all critical bugs in the critical bug table have 
been checked, i.e., no matches have been found (step 426), 
a dialog box is generated by which the user is informed that 
the error is likely due to an unknown bug (step 436). 
Authorization is then requested to remotely run the software 
from the vendor's platform using files on the user's platform 
(step 437'). If authorization is granted (step 439), the soft- 
ware is run from the vendor's platform (step 441). If not, the 
user is instructed to contact the vendor (step 407). 

The remote drive of this specific embodiment of the 
invention steps sequentially through the software commands 
of the user's software until an error condition is reached. 
That is, this technique attempts to recreate the error condi- 
tion originally encountered by the user without having to 
upload all of the user's files which, for a programmable logic 
design, for example, can be rather large. If, through this 
remote drive technique, a particular module of the user's 
software is identified as causing the problem (step 443), the 
defective module is reported to the user (step 445) and the 
module may be upgraded as described above with reference 
to steps 428-434 of FIG. 4a. If, one of the user's files is 
identified as causing the problem (step 447), the defective 
file is reported to the user along with vendor contact infor- 
mation for additional support in solving the identified prob- 



)5,579 Bl 

10 

lem (step 449). If the remote drive can neither identify 
defective software modules nor defective user files, the user 
is instructed to contact the vendor as described above (step 
407). 

5 The advantages of the above-described embodiments of 
the invention are manifest. Prominent among these is the 
fact that the time between the occurrence of an error in the 
operation of a software program and the diagnosis and 
correction of the error by the vendor is dramatically reduced. 

10 The user does not have to contact the vendor. Except for a 
few dialog boxes, the process is virtually automatic. Even in 
the case where the user's problem is the result of some 
unknown bug, the present invention provides alternative 
levels of troubleshooting designed to solve the problem as 

15 quickly and efficiently as possible. In each case, the vendor 
gets an accurate "snapshot" of the user's system and data 
files so that the error is correctly reproduced, thereby ensur- 
ing that the appropriate troubleshooting approach is taken. 
The importance of solving customer problems so quickly 

2Q cannot be overstated. The programmable logic design mar- 
ket is exemplary in this regard. Any periods of time in the 
design of a programmable logic device during which the 
design process is not moving forward is extremely costly. 
One of the main focuses for many vendors in this area of 

25 technology is reducing the amount of time required to get a 
chip to market. The efficiency with which the present 
invention facilitates and supports the design process is a 
significant advancement toward this goal. 

FIG. 5 is a flowchart 500 which illustrates the manner in 

30 which a user of software may access help files which are 
resident on a remote platform maintained by the vendor of 
the software. When, during operation of the software, the 
user requests help (step 502), the software on the user's 
platform determines whether access to the Internet is avail- 

35 able (step 504). If Internet access is not available, the user's 
software generates a dialog box which provides information 
to the user regarding how to obtain technical support from 
the vendor (step 506). If, however, Internet access is 
available, a dialog box is generated which informs the user 

40 about online help available from the vendor (step 508). If the 
user decides to use the online help (step 510), a connection 
between the user's platform and the vendor is established via 
the Internet (step 512). Otherwise, the user is provided with 
the technical support information at step 506. A menu of 

45 help topics is then downloaded from the vendor's platform 
and provided to the user (step 514). In response to the 
selection of a topic or topics by the user (step 516), help files 
associated with the selected topic(s) are downloaded to the 
user's platform (step 518). If the user does not make a 

50 selection, i.e., cancels the request, the support information 
described above with reference to step 506 is provided. 

The online technical support described above is another 
way in which the present invention facilitates optimal use of 
a software program. Because the help files are located on the 

55 vendor's platform, they can be updated as necessary to 
reflect the current state of the software and to incorporate 
any additional information which may become apparent to 
the vendor over lime. According to the invention, one way 
in which such information may be collected is through 

60 monitoring by the vendor of the help requests from its 
customer base. By compiling statistics regarding the use of 
its help utility, the vendor can determine which help files are 
most frequently requested. This information, in turn, may be 
useful in guiding the vendor's efforts to improve its product 

65 as well as in focusing technical support resources. 

The various aspects of the present invention all envision 
a greater connectivity between a software vendor and its 
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customers to provide a more responsive level of service and 
technical support. There are a number of other advantages 
which may also be realized as a result of this paradigm. For 
example, software vendors may take advantage of the fre- 
quent connections to customer platforms to provide infor- 
mation to their customer base regarding new and related 
products for which the customer might have an interest. 
More specifically based on information gathered about spe- 
cific customers over a period of time, a vendor may be able 
to provide such information in a format and with content 
specifically tailored to the needs of each customer. Thus, the 
present invention is also useful for facilitating an adaptive 
and forward-looking customer-vendor relationship, 

FIG. 6 illustrates an example of a computer system that 
may be used to execute the software of an embodiment of 
the invention. That is, system 601 is exemplary of, for 
example, workstation 100 and/or server 110 of FIG. 1. 
Computer system 601 includes a display 603, screen 605, 
cabinet 607, keyboard 609, and mouse 611. Mouse 611 may 
have one or more buttons for interacting with a graphical 
user interface. Cabinet 607 houses a CD-ROM drive 613, 
system memory and a hard drive (see FIG. 7) which may be 
utilized to store and retrieve software programs incorporat- 
ing computer code that implements the invention, data for 
use with the invention, and the like. Although the CD-ROM 
615 is shown as an exemplary computer readable storage 
medium, other computer readable storage media including 
floppy disks, tape, flash memory, system memory, and hard 
drives may be utilized. 

FIG. 7 shows a system block diagram of computer system 
601 used to execute the software of an embodiment of the 
invention. As in FIG. 6, computer system 601 includes 
monitor 603 and keyboard 609, and mouse 611. Computer 
system 601 further includes subsystems such as a central 
processor 701, system memory 703, fixed disk 705 (e.g., 
hard drive), removable disk 707 (e.g., CD-ROM drive), 
display adapter 709, sound card 711, speakers 713, and 
network interface 715. Other computer systems suitable for 
use with the invention may include additional or fewer 
subsystems. For example, another computer system could 
include more than one processor 701 (i.e., a multi-processor 
system), or a cache memory. 

The system bus architecture of computer system 601 is 
represented by arrows 717. However, these arrows are 
illustrative of any interconnection scheme serving to link the 
subsystems. For example, a local bus could be utilized to 
connect the central processor to the system memory and 
display adapter. Computer system 601 shown in FIG. 7 is but 
an example of a computer system suitable for use with the 
invention. Other computer architectures having different 
configurations of subsystems may also be utilized. 

While the invention has been particularly shown and 
described with reference to specific embodiments thereof, it 
will be understood by those skilled in the art that changes in 
the form and details of the disclosed embodiments may be 
made without departing from the spirit or scope of the 
invention. For example, several of the examples in this 
specification were related with reference to software for 
designing programmable logic devices. However, it is clear 
that the principles described herein may be applied to a wide 
variety of software programs. Therefore, the scope of the 
invention should be determined with reference to the 
appended claims. 

What is claimed is: 

1. A method for upgrading first software comprising: 
in response to operation of the first software on a first 

platform, establishing a connection between the first 

platform and a remote platform; 
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where first version data associated with the first software 
are different from second version data from the remote 
platform, overwriting a first portion of the first software 
with first updated code from the remote platform; and 

where known error data from the remote platform corre- 
spond to the first software, overwriting a second por- 
tion of the first software with second updated code. 

2. The method of claim 1 wherein the first software 
comprises a plurality of software modules, and wherein the 
overwriting occurs for each of the plurality of software 
modules for which the first and second version data are 
different. 

3. The method of claim 1 further comprising downloading 
the known error data from the remote platform to the first 
platform. 

4. The method of claim 1 wherein establishing the con- 
nection comprises establishing an Internet connection. 

5. The method of claim 4 further comprising determining 
whether access to the Internet is available. 

6. The method of claim 1 further comprising obtaining 
authorization from a user of the first software to establish the 
connection. 

7. The method of claim 6 further comprising, where 
authorization is not obtained, providing software support 
information to the user of the first software. 

8. The method of claim 1 further comprising shutting 
down operation of the first software before overwriting the 
first portion of the first software. 

9. The method of claim 1 further comprising, after over- 
writing the first portion of the first software, running a 
software diagnostic routine on the first software. 

10. The method of claim 1 further comprising download- 
ing the first version data from the remote platform to the first 
platform. 

11. At least one computer readable medium containing 
program instructions for upgrading first software, said at 
least one computer readable medium comprising: 

computer readable code for, in response to operation of 
the first software on a first platform, establishing a 
connection between the first platform and a remote 
platform; 

computer readable code for, where first version data 
associated with the first software are different from 
second version data from the remote platform, over- 
writing a first portion of the first software with first 
updated code from the remote platform; and 

computer readable code for, where known error data from 
the remote platform correspond to the first software, 
overwriting a second portion of the first software with 
second updated code. 

12. A computer data signal embodied in a carrier wave 
and representing sequences of instructions which, when 
executed by at least one processor, cause said at least one 
processor to upgrade first software by: 

in response to operation of the first software on a first 
platform, establishing a connection between the first 
platform and a remote platform; 

where first version data associated with the first software 
are different from second version data from the remote 
platform, overwriting a first portion of the first software 
with first updated code from the remote platform; and 

where known error data from the remote platform corre- 
spond to the first software, overwriting a second por- 
tion of the first software with second updated code. 

13. A computer readable medium containing program 
instructions corresponding to first software, the first soft- 
ware having been upgraded according to a method compris- 
ing: 



US 6,205,579 Bl 



13 



14 



in response to operation of the first software on a first 
platform, establishing a connection between the first 
platform and a remote platform; 

where first version data associated with the first software 
are different from second version data from the remote 
platform, overwriting a first portion of the first software 
with first updated code from the remote platform; and 

where known error data from the remote platform corre- 
spond to the first software, overwriting a second por- 
tion of the first software with second updated code. 

14. A method for troubleshooting first software compris- 
ing: 

in response to an error in operation of the first software on 

a first platform, establishing a connection between the 

first platform and a remote platform; 
where the error corresponds to known error data from the 

remote platform, overwriting a portion of the first 

software with updated code; 
where the error does not correspond to the known error 

data, uploading data files associated with the first 

software from the first platform to the remote platform 

via the connection; and 
reproducing the error on the remote platform using the 

data files. 

15. The method of claim 14 further comprising down- 
loading the known error data from the remote platform to the 
first platform. 

16. The method of claim 14 wherein establishing the 
connection comprises establishing an Internet connection. 

17. The method of claim 16 further comprising determin- 
ing whether access to the Internet is available. 

18. The method of claim 14 further comprising obtaining 
authorization from a user of the first software to establish the 
connection. 

19. The method of claim 18 further comprising, where 
authorization is not obtained, providing software support 
information to the user of the first software. 

20. The method of claim 14 further comprising shutting 
down operation of the first software before overwriting the 
first portion of the first software. 

21. The method of claim 14 further comprising, after 
overwriting the first portion of the first software, running a 
software diagnostic routine on the first software. 

22. The method of claim 14 further comprising obtaining 
authorization from a user of the first software for uploading 
the data files. 

23. The method of claim 22 further comprising, where 
authorization is not obtained, providing software support 
information to the user of the first software. 

24. The method of claim 14 further comprising, before 
uploading the data files, compiling information from the first 
platform regarding the data files. 

25. A method for troubleshooting first software compris- 
ing: 

in response to an error in operation of the first software on 
a first platform, establishing a connection between the 
first platform and a remote platform; 

where the error corresponds to known error data from the 
remote platform, overwriting a portion of the first 
software with updated code; and 

where the error does not correspond to the known error 
data, operating the first software on the first platform 
from the remote platform via the connection, thereby 
reproducing the error on the first platform. 

26. The method of claim 25 further comprising obtaining 
authorization from a user of the first software for operating 
the first software from the remote platform. 
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27. The method of claim 26 further comprising, where 
authorization is not obtained, providing software support 
information to the user of the first software. 

28. At least one computer readable medium containing 
program instructions for troubleshooting first software, said 
at least one computer readable medium comprising: 

computer readable code for, in response to an error in 
operation of the first software on a first platform, 
establishing a connection between the first platform and 
a remote platform; 

computer readable code for, where the error corresponds 
to known error data from the remote platform, over- 
writing a portion of the first software with updated 
code; and 

computer readable code for, where the error does not 
correspond to the known error data, operating the first 
software on the first platform from the remote platform 
via the connection, thereby reproducing the error on the 
first platform. 

29. A computer data signal embodied in a carrier wave 
and representing sequences of instructions which, when 
executed by at least one processor, cause said at least one 
processor to troubleshoot first software by: 

in response to an error in operation of the first software on 
a first platform, establishing a connection between the 
first platform and a remote platform; 

where the error corresponds to known error data from the 
remote platform, overwriting a portion of the first 
software with updated code; and 

where the error does not correspond to the known error 
data, operating the first software on the first platform 
from the remote platform via the connection, thereby 
reproducing the error on the first platform. 

30. A computer readable medium containing program 
instructions corresponding to first software, the first soft- 
ware having been troubleshot according to a method com- 
prising: 

in response to an error in operation of the first software on 
a first platform, establishing a connection between the 
first platform and a remote platform; 

where the error corresponds to known error data from the 
remote platform, overwriting a portion of the first 
software with updated code; and 

where the error does not correspond to the known error 
data operating the first software on the first platform 
from the remote platform via the connection, thereby 
reproducing the error on the first platform. 

31. A method for upgrading first software comprising: 
providing the first software including a first software 

module which, in response to operation of the first 
software on a first platform, is operable to establish a 
connection between the first platform and a remote 
platform, the first software having first version data 
associated therewith; 

where the first version data differ from second version 
data from the remote platform, transmitting first 
updated code from the remote platform to the first 
platform via the connection for overwriting a first 
portion of the first software; and 

transmitting the second version data from the remote 
platform to the first platform for comparison with the 
first version. 

32. The method of claim 31 wherein the first software 
comprises a plurality of software modules, and wherein 
updated code is transmitted for each of the plurality of 
software modules for which the first and second version data 
are different. 
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33. The method of claim 31 further comprising, where 
known error data from the remote platform correspond to the 
first software, transmitting second updated code for over- 
writing a second portion of the first software. 

34. The method of claim 33 further comprising transmit- 
ting the known error data from the remote platform to the 
first platform. 

35. The method of claim 31 wherein the connection 
comprises an Internet connection. 

36. The method of claim 35 wherein the first software 
module is operable to determine whether access to the 
Internet from the first platform is available. 

37. The method of claim 31 wherein the first software 
module is operable to solicit authorization from a user of the 
first software to establish the connection. 

38. The method of claim 31 wherein the first software 
module is operable to shut down operation of the first 
software before the first portion of the first software is 
overwritten. 

39. The method of claim 31 further comprising, after the 
first portion of the first software is overwritten, running a 
software diagnostic routine on the first software. 

40. A method for upgrading first software comprising: 
providing the first software including a first software 

module which, in response to operation of the first 
software on a first platform, is operable to establish a 
connection between the first platform and a remote 
platform, the first software having first version data 
associated therewith: 

where the first version data differ from second version 
data from the remote platform, transmitting first 
updated code from the remote platform to the first 
platform via the connection for overwriting a first 
portion of the first software wherein the first software 
module is operable to solicit authorization from a user 
of the first software to establish the connection, and 

where the authorization is not obtained, to provide soft- 
ware support information to the user of the first soft- 
ware. 

41. A method for troubleshooting first software compris- 
ing: 

providing the first software including a first software 
module which, in response to an error in operation of 
the first software on a first platform, is operable to 
establish a connection between the first platform and a 
remote platform; 

where the error corresponds to known error data from the 
remote platform, transmitting updated code from the 
remote platform to the first platform via the connection 
for overwriting a portion of the first software; 

where the error does not correspond to the known error 
data, uploading data files associated with the first 
software from the first platform to the remote platform 
via the connection; and 

attempting to reproduce the error on the remote platform 
using the data files. 

42. The method of claim 41 further comprising transmit- 
ting the known error data from the remote platform to the 
first platform. 

43. The method of claim 41 wherein the connection 
comprises an Internet connection. 

44. The method of claim 43 wherein the first software 
module is operable to determine whether access to the 
Internet from the first platform is available. 

45. The method of claim 41 wherein the first software 
module is operable to solicit authorization from a user of the 
first software to establish the connection. 
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46. The method of claim 41 wherein the first software 
module is operable to shut down operation of the first 
software before the first portion of the first software is 
overwritten. 

47. Hie method of claim 41 further comprising, after the 
first portion of the first software is overwritten, running a 
software diagnostic routine on the first software. 

48. The method of claim 41 wherein the first software 
module is operable to solicit authorization from a user of the 
first software for uploading the data files. 

49. The method of claim 41 further comprising, before 
uploading the data files, compiling information from the first 
platform regarding the data files. 

50. The method of claim 41 further comprising, where the 
error does not correspond to the known error data, operating 
the first software on the first platform from the remote 
platform via the connection, thereby attempting to reproduce 
the error on the first platform. 

51. The method of claim 41 wherein the first software 
module is operable to solicit authorization from a user of the 
first software for operating the first software from the remote 
platform. 

52. The method of claim 51 wherein the first software 
module is operable, where the authorization is not obtained, 
to provide software support information to the user of the 
first software. 

53. A method for troubleshooting first software compris- 
ing: 

providing the first software including a first software 
module which, in response to an error in operation of 
the first software on a first platform, is operable to 
establish a connection between the first platform and a 
remote platform; 

where the error corresponds to known error data from the 
remote platform, transmitting updated code from the 
remote platform to the first platform via the connection 
for overwriting a portion of the first software wherein 
the first software module is operable to solicit autho- 
rization from a user of the first software to establish the 
connection; and 

where the authorization is not obtained, to provide soft- 
ware support information to the user of the first soft- 
ware. 

54. A method for troubleshooting first software compris- 
ing: 

providing the first software including a first software 
module which, in response to an error in operation of 
the first software on a first platform is operable to 
establish a connection between the first platform and a 
remote platform; 

where the error corresponds to known error data from the 
remote platform, transmitting updated code from the 
remote platform to the first platform via the connection 
for overwriting a portion of the first software wherein 
the first software module is operable to solicit autho- 
rization from a user of the first software for uploading 
the data files; and 

where the authorization is not obtained, to provide soft- 
ware support information to the user of the first soft- 
ware. 

55. A computer system comprising: 
a central processing unit; 

a display; 

a keyboard; and 

memory having software stored therein including a soft- 
ware module which, in response to operation of the 
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software on the computer system, is operable to estab- 
lish a connection between the computer system and a 
remote platform, the software having first version data 
associated therewith, the software module also being 
operable, where the first version data differ from second s 
version data from the remote platform, to overwrite a 
portion of the software with updated code and where 
known error data from the remote platform correspond 
to the first software, overwriting a second portion of the 
first software with second updated code. 10 

56. A computer system comprising: 

a central processing unit; 

a display; 

a keyboard; and 
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memory having software stored therein including a soft- 
ware module which, in response to an error in operation 
of the software on the computer system, is operable to 
establish a connection between the computer system 
and a remote platform, the software module also being 
operable, where the error corresponds to known error 
data from the remote platform, to overwrite a portion of 
the software with updated code and where the error 
does not correspond to the known error data, operating 
the first software on the first platform from the remote 
platform via the connection, thereby reproducing the 
error on the first platform. 

* * * * * 



